Amendment 414 
Contract No. 229944 


To the Contract for the Design, Implementation, Operation and Maintenance of the 

Regional Fare Coordination System 

This Amendment 414 to the Contract for the Design, Implementation, Operation and 
Maintenance of the Regional Fare Coordination System is entered into this I'Sth day of 

A t<6 usT~ _, 2018, by and between Vix Technology (USA) Inc (formerly known as 

ERG Transit Systems (USA) Inc), a California corporation and wholly owned subsidiary of Vix 
Mobility Pty Ltd, an Australian corporation, (hereinafter referred to as the “Contractor”) and 
each of the following seven public transportation agencies (hereinafter referred to individually 
as an “Agency” or collectively as the “Agencies * 1 2 3 4 5 6 7 * * * 11 ): 

1. Central Puget Sound Regional Transit Authority ("Sound Transit") 

2. King County ("King County") 

3. Kitsap County Public Transportation Benefit Area ("Kitsap Transit") 

4. Pierce County Public Transportation Benefit Area (“Pierce Transit”) 

5. Snohomish County Public Transportation Benefit Area ("Community Transit") 

6. City of Everett (“Everett”) 

7. State of Washington, acting through the Washington State Department of 
Transportation, Washington State Ferries Division ("WSF") 

Recitals 

A. Effective April 29, 2003, each of the Agencies and the Contractor entered into Contract 
#229944 (“Contract”) to implement a Regional Fare Coordination System (“RFC 
System”) to establish a common fare system utilizing smart card technology. The 
Contractor is responsible for the development, implementation, operation and 
maintenance of the RFC System as specified in the Contract. 

B. The Agencies and the Contractor desire to amend Section VI of Exhibit 9, Price 
Schedule Special Programs, to compensate the Contractor for the work necessary to 
complete Point-To-Point Encryption. This work is performed per PA-ROF Point-To- 
Point Encryption (CR-12244) v6.1 as approved by the Agencies on June 13, 2018. 

C. The Parties agree that the Work necessary to complete Point-To-Point Encryption will 
be performed and compensated as described below. 
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Agreement 

Section 1.0 Description of Work 

Customer Service Terminal (CST) 

1.1 A new application mode will be introduced to the CST, PCI-C CST that will include 
functionality specific to this mode. 

1.2 The ERGcst installation package will be updated so that the user (Vix employee 
commissioning the CST) is prompted to select between the following modes: 

• PCI-C CST 

• WPCST 

• TSYS-Vital Integrated CST 

The PCI-C CST mode is intended to replace the functionality currently provided in the 
regular mode (TSYS-Vital Integrated CST). The screen layout and flow of the PCI-C CST 
will be modelled after the WPCST, which will also be updated with screen changes 
specified in this document. The WPCST ‘full month sales’ business rule will still apply to 
the WPCST and will not be incorporated into the PCI-C CST. 

The following changes apply specifically to the PCI-C CST 

1.3 The PCI-C CST will bypass the existing credit or debit card screens and instead the 
operator will be presented with the option to enter the last four digits of the card number 
and select the card type for credit transactions (MasterCard or Visa). Card type will default 
to Visa and can be changed by operator as required. These will be mandatory fields. This 
is similar to the existing WPCST, however, the authorization code and account holder 
name fields will be removed. This change applies to both the PCI-C & WPCST. 

1.4 When processing a sale using the credit card payment method, Visa will be used as the 
default card type. Debit card sales will also default the card type to Debit (not modifiable 
on all Debit Card Payment & Refund screens). This change applies to both the PCI-C & 
WPCST. 

1.5 Since the PCI-C CST does not perform the debit/credit card authorization, the only 
requirement for it is to record the fact that a credit/debit card was processed and to store 
the card type and last four digits of the card number. This is a statement of existing 
WPCST behavior that will be incorporated into the PCI-C CST. 
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1.6 When performing a Transaction Reversal, the Credit/Debit Card Refund screen will be 
prepopulated with the last four digits of the card associated with the original sale and is 
not modifiable. The card type will be prepopulated to Visa for the Credit Card Refund 
screen (modifiable) and Debit for the Debit Card Refund screen (not modifiable). Note; 
MS Retail does not record the card type in its system for credit card transactions, thus, 
the CST is defaulting this value; CST operators may need to change this value 
accordingly. This change applies to both the PCI-C & WPCST 

1.7 When performing a Non ORCA Product Refund, the Credit Card Refund screen will be 
prepopulated with the last four digits of the card originally used in the transaction and is 
not modifiable. The card type will be prepopulated to Visa for the Credit Card Refund 
screen (updateable) and Debit for the Debit Card Refund (no updateable) screen. Note; 
MS Retail does not record the card type in its system for credit card transactions, thus, 
the CST is defaulting this value; CST operators may need to change this value 
accordingly. This change applies to both the PCI-C & WPCST. 

1.8 In transaction failure scenarios, such as ORCA card commit failures or other errors that 
cause the CST to be unable to complete the transaction, where the credit/debit card 
payment methods were used, the CST will invoke a Credit/Debit Card Refund screen (for 
failed sales) or Credit/Debit Card Payment screen (for failed reversals) where the last four 
digits of the credit/debit card (not modifiable) and card type (not modifiable) will be 
prepopulated with the details previously entered by the operator. This is a statement of 
existing WPCST behavior that will be incorporated into the PCI-C CST. 

1.9 CST receipts currently show credit/debit card processing information for transactions 
involving these payment methods, using the sales receipt as an example: 

• Debit card 

DEBIT ACCOUNT 
DEBIT ************#### 

AUTH (authorization code) APPROVED 
AMOUNT $x.xx 

• Credit card 

CREDIT ACCOUNT 
MCA/ISA ************#### 

AUTH (authorization code) APPROVED 
AMOUNT $x.xx 

SIGN _ 
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The payment details for credit/debit card transactions on all receipts (i.e. sales, reversal, 
and refund) will be updated so that the authorization code/status, signature and 
corresponding text are removed. Using the sales receipt as an example: 

• Debit card 

DEBIT ACCOUNT 

|-|- ************^^l£^L 

AMOUNT $x.xx 

• Credit card 

CREDIT ACCOUNT 
MC A/ISA ************#### 

AMOUNT $x.xx 

There will be no change to packing slips. 

There will be no change to receipt functionality elsewhere in the RFC System (apart from 
the removal of credit/debit card processing details for CST transactions). 

This change applies to both the PCI-C & WPCST. 

1.10 Both customer and merchant copies of receipts will still be printed for transactions 
containing credit/debit card payment methods. This is a statement of existing WPCST 
behavior that will be incorporated into the PCI-C CST. 

1.11 The CST itself will not perform chargeback; this will need to be managed by the 
payment processor. This is a statement of existing WPCST behavior that will be 
incorporated into the PCI-C CST. 

1.12 Generated UD will only contain the card type and last four digits, the authorization 
number will not be captured. This change applies to both the PCI-C & WPCST. Online 
transaction history will still show the card type and last 4 digits associated with credit card 
transactions. 

1.13 Tender information stored in MS Retail will only capture the card type and last four 
digits; the approval code and account holder information will not be populated. This 
change applies to both the PCI-C & WPCST. 

1.14 Credit/debit card sales performed using the PCI-C CST will not be populated in MS 
Retail’s EDC batch and batch reports. Batch settlement will need to be performed via the 
payment processor. This is a statement of existing WPCST behavior that will be 
incorporated into the PCI-C CST. 
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1.15 All transactions carried out on the PCI-C CST in training mode will be created with the 
‘test mode’ flag set and will not be settled. This is a statement of existing WPCST behavior 
that will be incorporated into the PCI-C CST. 

1.16 Static text will be incorporated into the credit/debit card payment and refund screens. 
Static text to be provided by the Agencies. 

Waivers 

The PCI-C CST will be configured so that all credit/debit card processing will be carried out 
using Agency supplied hardware and internet connectivity. As such, there is no method for 
the Contractor to check and confirm there is a corresponding valid credit/debit card charge. 
This presents a risk that value is being added to an ORCA card when the payment has not 
been systematically authorized via the RFC system. The risk would be similar to a cash sale, 
where value is added to a card but no cash was received. Therefore, as a result of the Work 
performed under this Amendment 414 all payment authorization liability shifts to the Agencies 
and becomes the Agencies' responsibility. As there is no automated connection between the 
two processes, the Contractor accepts no liability for any fraudulent value added via this 
functionality added under this Amendment 414. 

The PCI-C CST will still process credit card information entered for product autoloads via 
Cybersource. Modification to this functionality is in scope for CR-12243 Cybersource 
Tokenization. 

Each Agency-chosen payment processor must implement their solution independently and 
such payment process solution cannot require any application to be installed on, connected 
to, or processed through the CST device or any peripheral. Access to third-party websites to 
view the payment processor transactions and settlement reports is available via the Chrome 
browser installed on they CST machines. The Contractor in no way represents that a selected 
payment processor or any other third-party website required by any payment processor will 
be available or work when used in connection with the PCI-C CST. The Contractor and 
Agencies agree that the use of third-party payment processors by the Agencies will be 
completely standalone from the CST and no Agency shall select any payment processor that 
requires any integration effort with the PCI-C CST. For clarity, this includes, but is not limited 
to, the following: 

• The Agencies shall not connect any peripherals to any CST machine. 

• The Agencies shall not load or execute any software applications (including peripheral 
drivers) on any CST machine. 

As the Contractor cannot guarantee the success of third-party websites (i.e. payment 
gateways) required by payment processors, the Agencies are responsible for ensuring the 
respective payment processor selected by each Agency will conform to the requirements set 
forth herein. 

Any Agency that fails to (1) implement the solution identified in Section 1 of this 
Amendment 414 and (2) comply with this Waivers section of Amendment 414 will be 
required to submit a new change request to the Contractor. 
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Documentation Updates 

The following documents will be updated as a result of this solution: 

• SEA-00045 Customer Service Terminal (DR 108) 

Section 2.0 Schedule 

2.1 The Work described in Section 1.0 will be completed in Maintenance Release 40 (MR 40) 

NOW, THEREFORE, in consideration of the mutual covenants contained herein, the 
sufficiency of which is hereby acknowledged, the Parties hereby agree to amend the Contract 
as follows: 

Section 3.0 Compensation Changes 

Section VI (Implementation) of Exhibit 9, Price Schedule, is hereby amended to read as 
follows: 

VI. IMPLEMENTATION 


SPECIAL PROGRAMS 


LUMP 

SUM 

COST 
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Point-To-Point Encryption 


TOTAL 

$96,479 


Section 4.0 Other Terms and Conditions 


All other provisions of the Contract not referenced in this Amendment Four Hundred and 
Fourteen shall remain in effect. 


IN WITNESS WHEREOF, authorized representative of the Agencies and the Contractor have 
signed their names in the spaces provided below. 


Vix Technology (USA) Inc. 



The Agencies 


Bv: _ 

Their: Me rr 
On behalf of the Agencies 
Date: J lb /mi ST_ 
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